Make `#[track_caller] async fn` track the caller, not the poller/awaiter by theemathas · Pull Request #163396 · rust-lang/rust

theemathas · 2026-09-27T08:36:14Z

An LLM was used to locate relevant code, suggest ideas, and review the code. However, I manually wrote all code, and I take all responsibility for all code written and all decisions made.

Tracking issue (async_fn_track_caller): #110011

Related tracking issue (closure_track_caller): #87417

The first commit adds extensive tests for behavior touched in this PR. Commits 2-7 are the actual implementation, and also modification of the tests to reflect this new behavior.

This PR makes coroutines desugared from #[track_caller] async fn track the caller of the function, not the poller/awaiter of the coroutine. This is done as per T-lang's decision at #110011 (comment). The implementation modifies AST lowering to add an upvar to the coroutine, which stores the relevant caller location.

In both codegen and in consteval/miri, we read the relevant upvar from the coroutine at the point in time where we need access to the &Location reference (either when we call the caller_location intrinsic, when we panic, or when we call another #[track_caller] function). We only dereference this reference as needed, when we actually need the Location information.

This PR changes the behavior of async fn, but not of async closures, due to difficulties I've noted at #t-compiler/help > Help with `async_fn_track_caller` @ 💬

This PR's implementation assumes that the desired behavior in #110011 (comment) is the behavior that I think makes the most sense.

This PR corrects the behavior of #163406 when the async_fn_track_caller feature is enabled, but does not give a warning when the feature is disabled (resulting in the pre-existing broken behavior).

The tests pass on cranelift when I run ./x test ui --test-codegen-backend cranelift -- async-await/track-caller/panic-track-caller-no-unwind.rs. (Cranelift doesn't support unwinding.)

r? compiler

theemathas · 2026-09-29T12:00:58Z

+        if is_in_trait_impl {
+            // Check if we need to "inherit" #[track_caller] from the trait definition.
+            let Some(trait_item_def_id) =
+                self.get_partial_res(node_id).and_then(|r| r.expect_full_res().opt_def_id())
+            else {
+                self.dcx().span_delayed_bug(span, "could not resolve trait item being implemented");
+                return false;
+            };
+            return find_attr!(self.tcx, trait_item_def_id, TrackCaller(_));
+        }


I don't understand what this is doing, but I'm doing the same thing as this existing code:

rust/compiler/rustc_ast_lowering/src/item.rs

Lines 1148 to 1155 in c1070d6

let (effective_ident, impl_kind) = if is_in_trait_impl {

let trait_item_def_id = self

.get_partial_res(i.id)

.and_then(|r| r.expect_full_res().opt_def_id())

.ok_or_else(|| {

self.dcx()

.span_delayed_bug(span, "could not resolve trait item being implemented")

});

View changes since the review

theemathas · 2026-09-29T12:09:28Z

+///
+/// FIXME(async_fn_track_caller): What if the Location is stored inside a coroutine upvar?
 fn resolve_tracked_call_location(body: &Body, inherited: Option<MirConst>) -> MirConst {


What is this, and do I need to modify it?

View changes since the review

rustbot · 2026-09-29T12:19:45Z

miri is developed in its own repository. If the Miri part of this change can be broken out, consider making this change to rust-lang/miri instead. However, if Miri needs adjusting for rustc changes, just ignore this message.

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_attr_ir

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

theemathas · 2026-10-01T14:57:54Z

I split up the implementation into multiple commits, hopefully making reviewing easier. (And also hopefully making it less confusing for me.)

theemathas · 2026-10-19T02:49:33Z

Rebased, since #163746 was merged. In the process, the commit previously cherry-picked from there was removed.

Here's a possibly more useful range-diff

I'll address Ralf's comments later.

…fJung consteval: Rework caller location handling Instead of walking up the call stack each time we need the caller location, we emulate the run time behavior of passing an implicit caller location argument in `#[track_caller]` functions. We record a representation of that argument in each frame. For inlined functions though, we still do a "stack walk" within that one frame. This PR is a prerequisite for rust-lang/rust#163396 Fixes rust-lang#5351

…ter. Part 1: AST lowering

…ter. Part 2: MIR building

…ter. Part 3: misc

rustbot · 2026-10-19T16:52:43Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

theemathas · 2026-10-19T16:52:54Z

And rebased again after #163262 was merged.

…ter. Part 4: codegen

…ter. Part 5: Miri

…ter. Part 6: Cranelift

theemathas · 2026-10-23T14:08:27Z

I've addressed @RalfJung's comments

theemathas · 2026-10-23T16:09:45Z

@RalfJung I've added a bunch of Miri tests, but the behavior doesn't make sense to me at all. Any suggestions on fixing these? 😅

RalfJung · 2026-10-24T11:05:31Z

@RalfJung I've added a bunch of Miri tests, but the behavior doesn't make sense to me at all. Any suggestions on fixing these? 😅

What exactly doesn't make sense? What needs fixing?

For the tests that involve the aliasing model I'd suggest switching to Tree Borrows, it has fewer unintuitive corner cases.

//@compile-flags: -Zmiri-tree-borrows

theemathas · 2026-10-24T15:20:07Z

@RalfJung I've rewritten the aliasing test, and edited some stuff.

Here are things I find confusing in the current state of the tests in src/tools/miri/tests/fail/async_fn_track_caller/:

The inconsistency between aliased-location-1.rs and aliased-location-2.rs seem to indicate that there's something special about the first poll of an async fn, which is odd.
I don't understand why null-location-ref.rs and uninit-location-ref are UB. We're only constructing references that point to invalid &Location references, right?

RalfJung · 2026-10-25T13:44:21Z

I don't know the MIR being run here, it is generated by the async lowering. You are asking me to spend a lot of time reverse engineering the exact steps that the auto-generated MIR is taking here. Is that worth it? Do you for some reason not want that code to have UB?
My guess would be that the MIR actually loads that field at its reference type and therefore it's UB for that field to be null / dangling. You can dig into this more yourself with something like the following that will show a trace of each MIR statement being executed:

MIRI_LOG=info ./x run miri -- src/tools/miri/tests/fail/async_fn_track_caller/null-location-ref.rs

seem to indicate that there's something special about the first poll of an async fn

It looks like the caller location isn't read every single time the async fn is polled. It's apparently only read on the first poll and the third poll. I don't know much about the sync lowering so I can't tell you why that is the case.

I don't understand the point of these tests, to be honest. Why should we have such fragile tests that probe implementation details of the generator lowerings?

theemathas · 2026-10-25T13:55:47Z

@RalfJung

Why should we have such fragile tests that probe implementation details of the generator lowerings?

I might have misunderstood your intentions. I thought that you wanted me to have the miri implementation of track_caller match the run time implementation so that Miri's UB always matches whatever the run time implementation assumes. Making sure that this is the case presumably requires fragile tests that reflect what things are assumed by the implementation. Am I misunderstanding what I was supposed to do?

theemathas · 2026-10-25T14:30:08Z

A potential alternative is to, in miri, require that all caller locations inside #[track_caller] async fn coroutines point to miri-allocated caller-location-specific allocations. This would detect more UB than what the runtime needs, but would make explaining the UB easier, and would still allow most if not all sane uses of such coroutines. I'm not entirely sure though about when exactly this check should be done, if we go with this approach.

theemathas · 2026-10-25T15:35:12Z

I just figured out why the tests behaved so weirdly. It's because I did a dumb and made a typed copy of the &Location references at 9e15722 (this PR). This typed copy runs on exactly the first poll of the coroutine. I'll get around to fixing this later, after which I expect the behaviour of stuff to make a lot more sense.

theemathas force-pushed the async-track-caller-not-poller branch 3 times, most recently from f21a754 to 7e01c99 Compare September 28, 2026 15:47

This comment has been minimized.

Sign in to view

theemathas force-pushed the async-track-caller-not-poller branch from 7e01c99 to c87bff0 Compare September 29, 2026 11:52

theemathas commented Sep 29, 2026

View reviewed changes

rustbot assigned oli-obk Sep 29, 2026

theemathas marked this pull request as ready for review September 29, 2026 12:19

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 29, 2026

RalfJung reviewed Sep 29, 2026

View reviewed changes

Comment thread compiler/rustc_const_eval/src/interpret/eval_context.rs Outdated

RalfJung reviewed Sep 29, 2026

View reviewed changes

Comment thread compiler/rustc_const_eval/src/interpret/operand.rs Outdated

theemathas force-pushed the async-track-caller-not-poller branch from c87bff0 to b14e6ed Compare September 29, 2026 13:07

RalfJung reviewed Sep 29, 2026

View reviewed changes

Comment thread compiler/rustc_const_eval/src/interpret/intrinsics.rs Outdated

This comment was marked as resolved.

Sign in to view

theemathas commented Sep 30, 2026

View reviewed changes

Comment thread compiler/rustc_codegen_ssa/src/mir/block.rs

theemathas force-pushed the async-track-caller-not-poller branch from b14e6ed to e1d818f Compare October 1, 2026 13:57

This comment has been minimized.

Sign in to view

theemathas force-pushed the async-track-caller-not-poller branch from e1d818f to 6fcdc09 Compare October 1, 2026 14:56

theemathas force-pushed the async-track-caller-not-poller branch 2 times, most recently from 6fcdc09 to 473dbf0 Compare October 1, 2026 15:01

theemathas changed the title ~~Make #[track_caller] async fn track the caller, not the poller~~ Make #[track_caller] async fn track the caller, not the poller/awaiter Oct 2, 2026

theemathas force-pushed the async-track-caller-not-poller branch from 473dbf0 to 57abba7 Compare October 2, 2026 11:02

theemathas force-pushed the async-track-caller-not-poller branch from f857e66 to b3015fc Compare October 19, 2026 02:48

This comment has been minimized.

Sign in to view

theemathas added 4 commits October 19, 2026 23:52

Improve tests for async track caller

26f14b6

Make #[track_caller] async fn track the caller, not the poller/awai…

9e15722

…ter. Part 1: AST lowering

Make #[track_caller] async fn track the caller, not the poller/awai…

fc0c575

…ter. Part 2: MIR building

Make #[track_caller] async fn track the caller, not the poller/awai…

0457a8c

…ter. Part 3: misc

theemathas force-pushed the async-track-caller-not-poller branch from b3015fc to e4d0827 Compare October 19, 2026 16:52

theemathas added 3 commits October 23, 2026 21:07

Make #[track_caller] async fn track the caller, not the poller/awai…

0aa909b

…ter. Part 4: codegen

Make #[track_caller] async fn track the caller, not the poller/awai…

cb45447

…ter. Part 5: Miri

Make #[track_caller] async fn track the caller, not the poller/awai…

fd39ca1

…ter. Part 6: Cranelift

theemathas force-pushed the async-track-caller-not-poller branch from e4d0827 to fd39ca1 Compare October 23, 2026 14:08

This comment has been minimized.

Sign in to view

This comment was marked as resolved.

Sign in to view

theemathas force-pushed the async-track-caller-not-poller branch from 9cdcb2d to 7bbcfe3 Compare October 24, 2026 15:15

This comment has been minimized.

Sign in to view

Add Miri UB tests

aa9ffe4

theemathas force-pushed the async-track-caller-not-poller branch from 7bbcfe3 to aa9ffe4 Compare October 25, 2026 08:52

	let (effective_ident, impl_kind) = if is_in_trait_impl {
	let trait_item_def_id = self
	.get_partial_res(i.id)
	.and_then(\|r\| r.expect_full_res().opt_def_id())
	.ok_or_else(\|\| {
	self.dcx()
	.span_delayed_bug(span, "could not resolve trait item being implemented")
	});

Conversation

theemathas commented Sep 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

theemathas Sep 29, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

theemathas Sep 29, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented Sep 29, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment was marked as resolved.

Uh oh!

This comment has been minimized.

theemathas commented Oct 1, 2026

Uh oh!

This comment has been minimized.

theemathas commented Oct 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Oct 19, 2026

Uh oh!

theemathas commented Oct 19, 2026

Uh oh!

theemathas commented Oct 23, 2026

Uh oh!

theemathas commented Oct 23, 2026

Uh oh!

This comment has been minimized.

This comment was marked as resolved.

This comment was marked as resolved.

RalfJung commented Oct 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

theemathas commented Oct 24, 2026

Uh oh!

This comment has been minimized.

RalfJung commented Oct 25, 2026

Uh oh!

theemathas commented Oct 25, 2026

Uh oh!

theemathas commented Oct 25, 2026

Uh oh!

theemathas commented Oct 25, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

theemathas commented Sep 27, 2026 •

edited

Loading

theemathas Sep 29, 2026 •

edited by rustbot

Loading

theemathas Sep 29, 2026 •

edited by rustbot

Loading

theemathas commented Oct 19, 2026 •

edited

Loading

RalfJung commented Oct 24, 2026 •

edited

Loading